2025년 리눅스 커널의 Rust 공식 도입

2025-12-23, G30DR

1. 서론: 34년 만의 거대한 전환점

2025년 12월, 일본 도쿄에서 개최된 리눅스 커널 관리자 서밋(Linux Kernel Maintainer Summit)은 운영체제 역사에 남을 기념비적인 결정을 내렸다. 리눅스 커널의 창시자 리누스 토르발스(Linus Torvalds)와 주요 서브시스템 관리자들은 지난 3년간 진행된 ‘Rust for Linux’ 프로젝트의 “실험적(experimental)” 지위를 공식적으로 해제하고, Rust를 리눅스 커널 개발의 영구적인 핵심 언어로 확정했다.1 이는 1991년 리눅스가 탄생한 이래 34년 동안 유지되어 온 C 언어(와 소수의 어셈블리어)의 절대적 독점 체제가 종식되었음을 의미한다.

이 결정은 단순한 프로그래밍 언어의 추가를 넘어선다. 그것은 전 세계 컴퓨팅 인프라를 지탱하는 가장 중요한 소프트웨어인 리눅스 커널이 직면한 구조적 한계—메모리 안전성, 동시성 관리의 난이도, 신규 개발자 유입의 정체—를 해결하기 위한 전략적 선택이자, 거대한 레거시 시스템이 현대적 소프트웨어 공학을 수용하는 과정에서 겪는 극심한 진통의 결과물이다. 본 보고서는 2025년 현재 리눅스 커널 팀이 Rust 도입을 확정한 배경과 그 필연적인 이유, 그리고 이 과정에서 발생한 기술적·문화적 충돌의 양상을 포괄적으로 분석한다. 또한, Android Binder, NVIDIA Nova, Apple AGX 등 주요 드라이버의 개발 현황과 최초의 Rust 커널 CVE 사례를 통해 이 변화가 실제 코드 레벨에서 어떤 영향을 미치고 있는지 심층적으로 규명한다.

2. Rust 도입의 전략적 배경과 기술적 당위성

리눅스 커널 커뮤니티가 보수적인 성향임에도 불구하고 Rust라는 급진적인 변화를 수용한 근본적인 이유는 ’안전성(Safety)’과 ’생산성(Productivity)’이라는 두 가지 키워드로 요약된다. 수십 년간 축적된 C 언어 기반의 커널 개발 방식은 하드웨어 성능을 극대화하는 데는 탁월했으나, 현대 컴퓨팅 환경이 요구하는 보안 수준과 복잡성 관리를 감당하기에는 구조적 한계에 봉착해 있었다.

2.1 메모리 안전성 위기(Memory Safety Crisis)와 해결책

운영체제 커널의 보안 취약점 통계는 Rust 도입의 가장 강력한 근거로 작용했다. 구글의 Android 보안 팀과 마이크로소프트, 그리고 ISRG(Internet Security Research Group)의 데이터에 따르면, 운영체제 커널에서 발견되는 치명적인 보안 취약점의 약 70%가 메모리 안전성 문제에서 기인한다.3

C 언어는 개발자에게 메모리 관리에 대한 전권을 부여하는 동시에 모든 책임을 지운다. kmalloc과 kfree로 대표되는 수동 메모리 관리는 개발자의 사소한 실수로도 버퍼 오버플로우(Buffer Overflow), 해제 후 사용(Use-After-Free), 이중 해제(Double-Free)와 같은 치명적인 버그를 유발한다. 이러한 버그는 단순한 시스템 충돌을 넘어, 공격자가 시스템의 제어권을 탈취할 수 있는 루트 권한 상승(Privilege Escalation) 공격의 통로가 되어왔다.

반면, Rust는 소유권(Ownership)과 빌림(Borrowing)이라는 독창적인 메모리 관리 모델을 통해 컴파일 시점에 메모리 안전성을 수학적으로 보장한다. Rust 컴파일러는 객체의 수명(Lifetime)을 추적하여, 유효하지 않은 메모리 접근이 발생할 가능성이 있는 코드는 아예 컴파일을 거부한다. 이는 런타임에 오버헤드를 발생시키는 가비지 컬렉터(Garbage Collector) 없이도 메모리 안전성을 확보할 수 있게 해주며, 성능 저하 없이 커널 레벨의 안전성을 담보할 수 있는 유일한 대안으로 평가받았다.5

2.2 “두려움 없는 동시성(Fearless Concurrency)“의 구현

멀티코어 프로세서가 보편화되면서 커널 내 동시성 프로그래밍의 중요성은 기하급수적으로 증가했다. 그러나 C 언어에서의 동시성 관리는 극도로 어렵고 오류가 발생하기 쉽다. 락(Lock)의 획득과 해제 순서를 개발자가 직접 관리해야 하며, 이는 데드락(Deadlock)이나 경쟁 상태(Race Condition)를 빈번하게 유발한다. 특히 데이터 레이스는 재현이 어렵고 디버깅이 까다로워 커널 안정성을 해치는 주범으로 지목되어 왔다.

Rust는 타입 시스템(Type System)을 통해 동시성 문제를 제어한다. Send와 Sync 트레이트는 스레드 간에 데이터를 안전하게 보낼 수 있는지, 혹은 공유할 수 있는지를 컴파일러에게 알려준다. 만약 데이터 레이스가 발생할 가능성이 있는 코드를 작성하면, Rust 컴파일러는 이를 오류로 처리한다. “만약 컴파일이 된다면, 데이터 레이스는 없다“는 Rust의 약속은 커널 개발자들이 복잡한 동시성 로직을 구현할 때 느끼는 두려움을 제거하고, 더욱 과감하고 효율적인 병렬 처리를 가능하게 한다.7

2.3 제로 비용 추상화(Zero-cost Abstractions)와 현대적 도구

커널 개발에서 C 언어가 선호되었던 이유는 하드웨어를 직접 제어할 수 있는 저수준 능력 때문이었다. 그러나 Rust는 “제로 비용 추상화“를 통해 고수준 언어의 편의성과 저수준 언어의 성능을 동시에 제공한다. 제네릭(Generics), 트레이트(Traits), 반복자(Iterators) 등의 기능은 컴파일 시점에 최적화된 기계어로 번역되어, 런타임 성능 손실 없이도 가독성이 높고 유지보수가 쉬운 코드를 작성할 수 있게 한다.5

또한, Rust는 cargo (패키지 관리 및 빌드 시스템), rustfmt (코드 포맷팅), clippy (린터), rustdoc (문서화 도구) 등 현대적인 개발 도구를 언어 차원에서 통합하여 제공한다. 이는 make 파일과 커스텀 스크립트, 그리고 파편화된 문서화 도구에 의존하던 기존 커널 개발 환경에 비해 개발 생산성을 획기적으로 높이는 요소로 작용한다. 특히, 새로운 세대의 개발자들이 커널 개발에 참여하는 진입 장벽을 낮추는 데 기여하고 있다.

비교 항목	C 언어 (기존 커널)	Rust (신규 도입)	커널 도입의 전략적 이점
메모리 관리	수동 관리 (Manual), 런타임 오류 위험 상존	소유권(Ownership) 기반 컴파일 타임 보장	보안 취약점 70% 감소 기대 (메모리 버그 원천 차단)
동시성 모델	락/아토믹 직접 제어, 데이터 레이스 위험 높음	타입 시스템(`Send`/`Sync`)을 통한 강제적 안전성	멀티코어 환경에서의 안정성 증대 및 디버깅 비용 절감
추상화 비용	매크로, 함수 포인터 (디버깅 난해, 타입 안정성 낮음)	제네릭, 트레이트 (Zero-cost Abstractions)	성능 저하 없는 깔끔한 API 설계, 코드 가독성 향상
오류 처리	정수형 리턴값 확인 (개발자가 누락하기 쉬움)	`Result<T, E>` 타입을 통한 강제적 오류 처리	예외 상황에 대한 명시적이고 안전한 처리 보장
개발 생태계	파편화된 도구, 텍스트 기반 문서화	통합된 툴체인, 코드 기반 문서 자동화	신규 개발자 유입 촉진 및 개발 경험(DX) 개선

3. 2025년 현재 Rust for Linux 프로젝트의 기술적 현황

2025년 12월 기준, 리눅스 커널 내 Rust 도입은 단순한 “실험” 단계를 넘어 실제 프로덕션 환경에 투입되는 단계에 도달했다. 리눅스 6.13에서 6.14로 이어지는 개발 주기 동안, Rust 인프라는 비약적으로 발전했으며, 주요 하드웨어 드라이버들이 Rust로 재작성되거나 신규 개발되어 메인라인에 병합되었다.

3.1 Android Binder 드라이버: 프로덕션 성공 사례

Android 운영체제의 핵심인 Binder 드라이버의 Rust 재작성은 Rust for Linux 프로젝트의 가장 큰 성과 중 하나다. Binder는 안드로이드 내 모든 앱과 시스템 서비스 간의 통신(IPC)을 담당하는 중추 신경망으로, 성능과 보안이 극도로 중요한 컴포넌트다.

재작성의 의의: 기존 C로 작성된 Binder 드라이버는 수년 동안 수많은 보안 패치와 복잡도 증가를 겪어왔다. 이를 Rust로 재작성한 것은, Rust가 커널의 가장 복잡하고 성능 민감한 부분을 대체할 수 있음을 증명하기 위한 시도였다.10
현황 (2025년 말): Rust 기반 Binder 드라이버는 리눅스 6.18 커널에 병합되었으며, 2025년 하반기 출시된 Android 16 기기부터 기본 활성화되어 수억 대의 디바이스에서 구동되고 있다.1
기술적 성과: Rust의 타입 시스템은 Binder의 복잡한 객체 수명 관리와 락킹 로직을 단순화했으며, 기존 C 구현체와 동등하거나 더 나은 성능을 보이면서도 메모리 안전성을 확보했다. 특히, ashmem (익명 공유 메모리) 할당자 또한 Rust로 구현되어 안드로이드 생태계의 Rust 전환을 가속화했다.12

3.2 NVIDIA ‘Nova’ GPU 드라이버: 차세대 그래픽의 기반

NVIDIA GPU를 위한 새로운 오픈소스 드라이버인 ’Nova’는 Rust 도입의 전략적 가치를 보여주는 대표적인 사례다.

배경: NVIDIA의 최신 GPU 아키텍처(Ampere 이후)는 GPU 내부의 GSP(GPU System Processor)가 초기화와 전력 관리 등 하드웨어 제어의 상당 부분을 담당하도록 변경되었다. 기존의 C 기반 Nouveau 드라이버는 구형 아키텍처 지원과 GSP 도입에 따른 구조적 변화를 동시에 수용하는 데 어려움을 겪었다.13
Rust의 역할: Nova 드라이버는 GSP 기반의 최신 GPU만을 타겟으로 하며, 처음부터 Rust로 설계되었다. Rust의 강력한 추상화 기능은 GSP 펌웨어와의 통신 프로토콜을 안전하게 모델링하고, 복잡한 비동기 명령 큐 관리를 효율적으로 구현하는 데 핵심적인 역할을 했다.
진척 상황: 리눅스 6.19 커널에 Nova의 초기 코드가 병합되었으며, 2025년 12월 기준으로 GSP 초기화, 부팅, 그리고 기본적인 디스플레이 출력이 가능한 수준에 도달했다.13 이는 2026년 완전한 기능 지원을 목표로 순항 중임을 보여준다.

3.3 Apple Silicon (Asahi Linux) AGX 드라이버

Apple의 M1, M2, M3 등 독자적인 Silicon 칩셋을 리눅스에서 구동하기 위한 Asahi Linux 프로젝트는 GPU 드라이버(AGX) 개발에 Rust를 적극적으로 활용했다.

리버스 엔지니어링과 Rust: 문서가 없는 Apple의 GPU 하드웨어를 리버스 엔지니어링하여 드라이버를 만드는 과정에서, Rust의 타입 시스템은 하드웨어의 동작을 안전하게 모델링하고 추론하는 데 큰 도움을 주었다. 잘못된 레지스터 접근을 컴파일러가 막아줌으로써 하드웨어 손상 위험을 줄이고 개발 속도를 높일 수 있었다.15
현황: Rust로 작성된 AGX 드라이버는 현재 메인라인 커널에 포함되어 있으며, 복잡한 그래픽 워크로드를 처리할 수 있는 수준으로 성숙했다. 이는 리눅스 커널 내에서 가장 복잡한 Rust 코드 중 하나로 꼽힌다.16

3.4 NVMe 및 기타 인프라 드라이버

NVMe 드라이버: 고성능 SSD를 위한 NVMe 드라이버 역시 Rust로 구현되어, Rust가 I/O 처리량이 높은 스토리지 서브시스템에서도 C와 대등한 성능을 낼 수 있음을 입증했다.18
인프라 확장: 2025년에는 드라이버뿐만 아니라 PHY 드라이버, Null Block 드라이버, 그리고 커널 패닉 시 화면에 QR 코드를 띄워주는 DRM Panic 기능 등 다양한 서브시스템으로 Rust 도입이 확장되었다.3 이는 Rust가 특정 틈새 영역이 아닌 커널 전반의 범용 언어로 자리 잡고 있음을 시사한다.

3.5 툴체인의 성숙: GCC 지원과 배포판의 수용

초기 Rust 도입의 기술적 장벽 중 하나는 LLVM/Clang 컴파일러에 대한 의존성이었다. 리눅스 커널은 전통적으로 GCC를 표준으로 사용하며, GCC만 지원하는 다양한 아키텍처가 존재하기 때문이다.

rustc_codegen_gcc: 2025년 말, GCC의 백엔드를 사용하여 Rust 코드를 컴파일하는 rustc_codegen_gcc 프로젝트가 실용적인 단계에 진입했다. 이를 통해 개발자들은 GCC 툴체인 하나만으로도 C와 Rust가 혼합된 커널을 빌드할 수 있게 되었다.12
배포판의 움직임: Debian과 같은 보수적인 리눅스 배포판은 2026년 5월부터 Rust 툴체인을 패키지 빌드의 필수 요구사항(Hard Requirement)으로 지정할 계획을 발표했다.12 이는 Rust 커널이 주류 리눅스 배포판의 기본 커널로 채택되는 ’티핑 포인트(Tipping Point)’가 2025년에 형성되었음을 의미한다.

4. “내전(Civil War)”: 커널 커뮤니티의 갈등과 진통

Rust의 기술적 성과 이면에는 커널 커뮤니티를 분열시킨 심각한 사회적, 문화적 갈등이 존재했다. 2024년 말부터 2025년에 걸쳐 발생한 일련의 사건들은 기존 C 언어 중심의 보수적인 관리자(Maintainer)들과 Rust 도입을 추진하는 진보적인 개발자들 사이의 “임피던스 불일치(Impedance Mismatch)“를 적나라하게 드러냈다.

4.1 DMA 추상화 논쟁과 “암(Cancer)” 발언

갈등의 최전선은 커널의 핵심 기능인 DMA(Direct Memory Access) 서브시스템이었다. Rust 드라이버가 하드웨어와 데이터를 주고받기 위해서는 C로 작성된 DMA API를 안전하게 사용할 수 있는 Rust 추상화 계층(Abstraction Layer)이 필수적이었다.

충돌의 발단: Rust for Linux 팀은 DMA API를 감싸는 안전한 Rust 바인딩 패치를 제출했다. 그러나 DMA 서브시스템의 핵심 관리자인 크리스토프 헬비그(Christoph Hellwig)는 이 패치를 단호하게 거부했다.
반대의 논리: 헬비그는 “kernel/dma 디렉토리에 Rust 코드를 넣지 말라“고 요구하며, Rust 바인딩이 커널 내부의 헤더 파일과 서브시스템 곳곳에 침투하는 것을 “암(Cancer)“에 비유하며 강하게 비판했다. 그는 다중 언어 프로젝트를 유지보수하는 복잡성을 감당할 의사가 없으며, Rust 개발자들이 C 인터페이스의 변경에 따른 부담을 기존 C 관리자들에게 전가해서는 안 된다고 주장했다.21
Rust 진영의 항변: 다니로 크룸리히(Danilo Krummrich)를 비롯한 Rust 개발자들은 해당 추상화 계층을 Rust 팀이 전적으로 유지보수하겠다고 제안했다. 그들은 안전한 API를 제공하기 위해서는 커널 내부의 C API와 밀접하게 연동되는 바인딩이 필수적이며, 이를 거부하는 것은 사실상 Rust 드라이버 개발을 원천 봉쇄하는 것이라고 반박했다.23

4.2 핵심 기여자의 이탈과 “비기술적 넌센스”

이러한 적대적인 환경은 프로젝트의 핵심 인력 이탈로 이어졌다.

Wedson Almeida Filho의 사임: Microsoft 엔지니어이자 Rust for Linux 프로젝트의 초기 리더 중 한 명이었던 그는 2024년 9월, “비기술적 넌센스(non-technical nonsense)“에 지쳤다며 프로젝트를 떠났다. 그는 기술적인 토론이 아닌 정치적이고 감정적인 반대에 부딪혀 에너지를 소모하는 것에 회의감을 느꼈다고 밝혔다.16
Hector Martin의 사임과 폭로: Apple Silicon (Asahi Linux) 프로젝트를 이끌던 헥터 마틴(Hector Martin)은 2025년 2월, 커널 관리자 직과 Asahi 프로젝트 리드 직을 모두 사임했다. 그는 헬비그를 비롯한 일부 관리자들의 독선적이고 공격적인 태도가 커널 개발 문화를 망치고 있다며 공개적으로 비난했다. 마틴은 리누스 토르발스가 이러한 “독성(Toxic)” 문화를 방관하고 있다고 지적했다.15

4.3 리누스 토르발스의 개입과 리더십의 방향

갈등이 격화되자 리눅스 커널의 최종 결정권자인 리누스 토르발스는 명확한 입장을 정리했다. 그의 개입은 양비론적이었으나, 결론은 Rust의 잔류였다.

“Rust는 남는다”: 토르발스는 비공개 대화와 메일링 리스트를 통해 “일부 관리자가 반대하더라도 나는 Rust 코드를 머지(Merge)할 것“이라는 의지를 확고히 했다.27 이는 특정 서브시스템 관리자의 거부권(Veto)을 무력화하고, 프로젝트 전체의 방향성을 Rust 수용으로 고정한 결정이었다.
“소셜 미디어 여론전 금지”: 동시에 토르발스는 헥터 마틴이 소셜 미디어를 통해 커널 관리자들을 비판하고 외부 여론을 동원하려 한 행위(Brigading)에 대해 강하게 질책했다. 그는 “문제는 너 자신일 수 있다“며, 기술적 이견은 커널 메일링 리스트 내의 기술적 토론으로 해결해야지, 외부의 압력을 이용해 해결하려 해서는 안 된다는 보수적인 입장을 고수했다.29

이 일련의 사태는 기술적 우수성만으로는 거대한 오픈소스 프로젝트의 관성을 이길 수 없으며, 기존 구성원들과의 융합 과정에서 발생하는 “문화적 마찰비용“이 얼마나 큰지를 보여주는 사례로 남았다.

5. 심층 분석: 최초의 Rust 커널 CVE (CVE-2025-68260)

2025년 12월 16일, 리눅스 커널의 Rust 코드에서 최초의 공식 보안 취약점인 CVE-2025-68260이 할당되었다.31 이는 Rust 회의론자들에게는 공격의 빌미를, 지지자들에게는 역설적으로 Rust의 가치를 증명하는 계기를 제공했다.

5.1 취약점의 본질

이 취약점은 Rust로 재작성된 Android Binder 드라이버 (rust_binder) 내의 Node::release 함수에서 발생했다.

원인: 리스트(death_list)에서 노드를 제거하는 과정에서 발생한 **경쟁 상태(Race Condition)**였다. 락(Lock)을 해제한 상태에서 임시 리스트를 순회하는 동안, 다른 스레드가 해당 리스트에 접근하여 포인터 연결이 꼬이는 현상이 발생했다.31
Unsafe의 사용: 이 문제는 Rust의 unsafe 블록 내에서 발생했다. Rust는 안전하지 않은 작업을 unsafe 블록으로 격리하는데, 개발자가 이 블록 내에서 동시성 불변 조건(Invariant)을 잘못 가정했기 때문에 발생한 버그였다.31

5.2 “크래시(Crash)일 뿐, 해킹은 아니다”

이 사건의 가장 중요한 함의는 버그의 **영향 범위(Impact)**에 있다.

C 언어였다면: 유사한 연결 리스트(Linked List) 오염 버그가 C 언어에서 발생했다면, 이는 전형적인 **메모리 커럽션(Memory Corruption)**으로 이어져 공격자가 임의의 코드를 실행(RCE)하거나 루트 권한을 탈취할 수 있는 치명적인 취약점이 되었을 가능성이 높다.
Rust에서는: Rust의 메모리 안전성 모델 덕분에, 이 버그는 메모리 전체를 오염시키지 않고 해당 프로세스나 커널을 패닉(Panic) 상태로 빠뜨려 시스템을 중단시키는 데 그쳤다.33 즉, 시스템이 멈출지언정 해커에게 제어권을 넘겨주지는 않는다는 “실패의 안전성(Fail-safe)“이 증명된 것이다.

5.3 숫자의 대조

그렉 크로아-하트만(Greg Kroah-Hartman)은 이 CVE가 발표된 날, **“같은 날 C 코드베이스에서는 159개의 CVE가 보고되었다”**는 점을 지적했다.34 159 대 1이라는 숫자는 Rust가 모든 버그를 없애주는 마법은 아니지만, 버그의 발생 빈도와 심각도를 획기적으로 낮춰준다는 사실을 극명하게 보여주었다. 이는 Rust 도입의 정당성을 흔들기는커녕 오히려 강화하는 논거로 작용했다.

6. 결론 및 2026년 이후의 전망

2025년은 리눅스 커널 역사에서 “Rust의 시대“가 공식적으로 개막한 원년으로 기록될 것이다. 도쿄 서밋에서의 결정은 리눅스가 더 이상 과거의 유산에 머무르지 않고, 안전성과 현대성을 향해 나아가겠다는 강력한 의지의 표명이다.

6.1 현황 요약

제도적 확립: Rust는 더 이상 실험적인 프로젝트가 아니며, 커널의 1급 시민(First-class Citizen)으로 승격되었다.
기술적 침투: Android, NVIDIA, Apple Silicon 등 수십억 대의 디바이스에 영향을 미치는 핵심 드라이버들이 이미 Rust로 구동되고 있다.
생태계 완성: GCC 지원과 배포판들의 수용으로 Rust 커널을 위한 인프라가 완성 단계에 접어들었다.

6.2 향후 전망 및 과제

2026년부터는 “티핑 포인트“를 넘어선 Rust의 확산이 가속화될 것이다. 그렉 크로아-하트만이 예고한 대로, PCI 및 플랫폼 드라이버 바인딩이 안정화되면 개별 하드웨어 제조사들이 신규 드라이버를 Rust로 제출하는 사례가 폭발적으로 증가할 것이다.3

그러나 과제도 남아있다. “내전“으로 드러난 기존 C 개발자들과의 문화적 갈등을 봉합하고, 두 언어가 공존하는 하이브리드 커널의 복잡성을 관리하는 것은 리눅스 커뮤니티의 숙제로 남았다. 또한, C API의 변경이 Rust 바인딩을 깨뜨리는 구조적 문제를 해결하기 위해, 장기적으로는 커널 내부 API의 안정화나 자동화된 바인딩 생성 도구의 고도화가 요구된다.

결론적으로, 리눅스 커널 팀은 내부의 격렬한 저항과 진통에도 불구하고 “안전성“이라는 시대적 요구에 부응하기 위해 Rust를 선택했다. 이는 리눅스가 단순한 취미 프로젝트를 넘어 전 세계의 신뢰할 수 있는 인프라로 지속 가능하기 위한, 고통스럽지만 필수적인 진화의 과정이다. 2025년의 리눅스는 이제 C와 Rust라는 두 개의 심장을 가진 하이브리드 엔진으로 재탄생했다.

7. 참고 자료

New Linux Patch Confirms: Rust Experiment Is Done, Rust Is Here To Stay - Phoronix, https://www.phoronix.com/news/Rust-To-Stay-Linux-Kernel
Rust Declared Permanent in Linux Kernel: C Era Ends | byteiota, https://byteiota.com/rust-declared-permanent-in-linux-kernel-c-era-ends/
An Update on Memory Safety in the Linux Kernel - Prossimo, https://www.memorysafety.org/blog/linux-kernel-2025-update/
Rust Goes Mainstream in the Linux Kernel - The New Stack, https://thenewstack.io/rust-goes-mainstream-in-the-linux-kernel/
Unraveling the Wonders of Rust Files in the Linux Kernel Source Code - Medium, https://medium.com/@mayank16maniac03/unraveling-the-wonders-of-rust-files-in-the-linux-kernel-source-code-b8269f7bb28e
Memory-Safety Challenge Considered Solved? An In-Depth Study with All Rust CVEs - arXiv, https://arxiv.org/pdf/2003.03296
Fearless Concurrency - The Rust Programming Language, https://doc.rust-lang.org/book/ch16-00-concurrency.html
An Empirical Study of Rust-for-Linux: The Success, Dissatisfaction, and Compromise - Reddit, https://www.reddit.com/r/rust/comments/1e0lotn/an_empirical_study_of_rustforlinux_the_success/
An Empirical Study of Rust-for-Linux: The Success, Dissatisfaction, and Compromise - USENIX, https://www.usenix.org/system/files/atc24-li-hongyu.pdf
Android Binder Driver - Rust for Linux, https://rust-for-linux.com/android-binder-driver
A Rust implementation of Android’s Binder - LWN.net, https://lwn.net/Articles/953116/
Rust boosted by permanent adoption for Linux kernel code - devclass, https://devclass.com/2025/12/15/rust-boosted-by-permanent-adoption-for-linux-kernel-code/
More NVIDIA Nova Enablement For Linux 6.19 With Other Rust Graphics Driver Code, https://www.phoronix.com/news/DRM-Rust-Code-For-Linux-6.19
A Rusty Odyssey: A Timeline of Rust in the DRM subsystem - Igalia, https://www.igalia.com/downloads/slides/mcanal-ARustyOdyssey.pdf
Resigning as Asahi Linux project lead - marcan.st, https://marcan.st/2025/02/resigning-as-asahi-linux-project-lead/
Rust drivers expected to become more common in Linux kernel - The Register, https://www.theregister.com/2025/03/10/rust_drivers_expected_to_become/
Rust for Linux - Wikipedia, https://en.wikipedia.org/wiki/Rust_for_Linux
Rust in Linux’s Kernel ‘is No Longer Experimental’ - General - Gnoppix Forum, https://forum.gnoppix.org/t/rust-in-linuxs-kernel-is-no-longer-experimental/3328
NVMe Driver - Rust for Linux, https://rust-for-linux.com/nvme-driver
rustc_codegen_gcc - Rust for Linux, https://rust-for-linux.com/rustc_codegen_gcc
Mixing Rust and C in Linux Likened To Cancer By Kernel Maintainer - Slashdot, https://linux.slashdot.org/story/25/02/06/1830233/mixing-rust-and-c-in-linux-likened-to-cancer-by-kernel-maintainer
Mixing Rust and C in Linux likened to cancer by kernel maintainer - The Register, https://www.theregister.com/2025/02/05/mixing_rust_and_c_linux/
Resistance to Rust abstractions for DMA mapping in Linux kernel [LWM] - Reddit, https://www.reddit.com/r/linux/comments/1igrime/resistance_to_rust_abstractions_for_dma_mapping/
Rust Integration in Linux Kernel Faces Challenges but Shows Progress - The New Stack, https://thenewstack.io/rust-integration-in-linux-kernel-faces-challenges-but-shows-progress/
The Linux Rust Drama Reaches a NEW High.. More Step Down - YouTube, https://www.youtube.com/watch?v=P57qiQHqFho
Hector Martin Resigns From The Asahi Linux Project - Phoronix, https://www.phoronix.com/news/Hector-Martin-Resigns-Asahi
Linus Torvalds Would Reportedly Merge Rust Kernel Code Over Maintainer Objections, https://linux.slashdot.org/story/25/02/18/227222/linus-torvalds-would-reportedly-merge-rust-kernel-code-over-maintainer-objections
Linus Torvalds Would Reportedly Merge Rust Kernel Code Over Maintainer Objections, https://www.phoronix.com/news/Torvalds-Override-On-Rust-Code
‘Maybe the problem is you’ … Linus Torvalds wades into Linux kernel Rust driver drama, https://forums.freebsd.org/threads/maybe-the-problem-is-you-linus-torvalds-wades-into-linux-kernel-rust-driver-drama.96732/
Linus Torvalds’ take on the latest Rust-Kernel drama : r/linux - Reddit, https://www.reddit.com/r/linux/comments/1ijxber/linus_torvalds_take_on_the_latest_rustkernel_drama/
Rust’s first kernel CVE (CVE-2025-68260): what does it really say about unsafe? - Reddit, https://www.reddit.com/r/rust/comments/1pq94dr/rusts_first_kernel_cve_cve202568260_what_does_it/
CVE-2025-68260 Deep Dive: Linux Kernel’s First Rust CVE Isn’t “Rust Failing”—It’s Concurrency Semantics Failing - Penligent, https://www.penligent.ai/hackinglabs/cve-2025-68260-deep-dive-linux-kernels-first-rust-cve-isnt-rust-failing-its-concurrency-semantics-failing/
Linux Kernel Rust Code Sees Its First CVE Vulnerability - Phoronix, https://www.phoronix.com/news/First-Linux-Rust-CVE
The First Rust CVE in Linux Kernel Only Makes Your System Crash - It’s FOSS, https://itsfoss.com/news/first-linux-kernel-rust-cve/
Is Unsafe the Original Sin? A Deep Dive into the First CVE After Rust Entered the Linux Kernel - DEV Community, https://dev.to/zhanghandong/is-unsafe-the-original-sin-a-deep-dive-into-the-first-cve-after-rust-entered-the-linux-kernel-39k